Generally, to fix this kind of problem you either (a) avoid logging the sensitive value at all, or (b) log only a redacted/hashed/shortened representation that is not directly usable by an attacker. For error objects, you should avoid propagating or logging detailed structs that may contain sensitive fields; instead, log higher-level, sanitized error messages.

In this specific case, the clearest minimal fix is in relayer/aptos_service.go:

1. Stop logging the full enqueueErr object coming back from EnqueueWithEntryFunction, because that error may wrap an AptosTx or otherwise include the FromAddress/authKey or related data.
2. Replace that with a generic or less-detailed message that does not include the error itself in the log fields, while still returning the wrapped error to the caller so functional behavior is unchanged.
3. Optionally, you could still log a non-sensitive summary (e.g., just "failed": true) alongside txID, but exclude enqueueErr.

We do not need to alter relayer/utils/address.go or relayer/txm/txm.go to fix the concrete logging sink flagged by CodeQL; enqueueTransaction already logs a formatted transaction (fmt.Errorf("failed to enqueue tx: %+v", tx)) but CodeQL’s reported sink here is the enqueueErr log in aptos_service.go. To keep the change as small and non-disruptive as possible, we will modify only the logging statement at line 216 in relayer/aptos_service.go to remove the error value from the structured log while preserving the returned error.

Concretely:

• In relayer/aptos_service.go, around lines 215–217, replace:

if enqueueErr != nil {
    s.logger.Errorw("SubmitTransaction: EnqueueWithEntryFunction failed", "txID", txID, "error", enqueueErr)
    return nil, fmt.Errorf("failed to enqueue transaction: %w", enqueueErr)
}

with a version that logs without the error object, e.g.:

if enqueueErr != nil {
    s.logger.Errorw("SubmitTransaction: EnqueueWithEntryFunction failed", "txID", txID)
    return nil, fmt.Errorf("failed to enqueue transaction: %w", enqueueErr)
}

This preserves behavior for callers (the returned error is unchanged) but ensures that potentially sensitive content in enqueueErr is not written to logs.

No new imports or helper methods are required.